A child application that can be integrated into a parent application is indispensable for a system that adopts plug-in technology, such as Workplace Client Technology (WCT) wherein the child application usually takes the form of a plug-in.
On an operating system (OS) that supports window identifiers in different processes, for example on MICROSOFT® WINDOWS® system, application integration is implemented with OLE/ActiveX, and thus Application Plug-in is implemented as well. As for an application integration of non-OLE/ActiveX control, a more general approach is needed. In fact, if an OS were to provide applications in different processes with window identifiers that are process independent, it would be easy to build up application integration between processes. For instance, on MICROSOFT® WINDOWS® system we are able to build up parent/child relationships between windows in the different processes because each of the windows is identified by a process independent handle, hWnd.
Thus where a user wants to use another application (B) as a plug-in in its own application (A), the approach mentioned above would appear to be of particular use in the following three adverse situations: wherein the OS provides no process independent window identifier; wherein application B does not provide the user with a control that conforms to some component standard; and wherein application B is a very complex application which requires a great effort to rewrite so as to conform to some component standard. In addition, by this approach, the function of the plug-in application may be revised with minimal change to its original structure.
However, on an OS that does not support a process independent window identifier, for example on APPLE® MAC OS X® system, it is hard to implement application integration between processes in the windowing system level. That is because, when an application is created by an application manager, the OS is unable to provide applications in different processes with process independent identifiers. Taking MAC OS X® system as an example, when a window is created by a Window Manager, the user may obtain WindowRef that identifies this window. But this WindowRef is a pointer variable which is valid only in its own process. Moreover, the structure of WindowRef is opaque (internal structure). This means that even though the memory pointed to may be accessed by WindowRef from other processes, the window cannot be operated on directly. In fact, WindowRef is only an index number of some windows controlled by Window Manager. Window Manager can control all of the windows, but we can't. So, on APPLE® MAC OS X® system, parent/child relationships between windows in different processes cannot be implemented in the windowing system level. As a consequence, on this kind of OS there is a need to simulate this relationship to implement application integration between processes in windowing system level. For example, on APPLE® MAC OS X® system, parent/child relationships between windows in different processes are simulated so as to implement Application Plug-in.
Due to the problems described above, it is very difficult to secure normal activities of user interfaces in application integration. Normally, in activities of parent/child windows, the following apply: (1) the child window will always be in front of the parent window (Z order); (2) the child window and parent window will move together; (3) the child window and parent window will resize together; (4) the child window and parent window will Maximize/Minimize together; and (5) events of the child window can be propagated to the parent window. Activities (2) to (5) can be performed with an that does not support process independent window identifiers, such as on APPLE® MAC OS X® system. However, activity (1) cannot be simulated with existing functions because the correct Z order cannot be secured between windows in different processes.
Two disadvantages remain in the course of implementation of application integration between processes on an OS that does not support process independent window identifiers. First, since the prior art usually adopts inter-process communication (IIPC), the cost will be great when frequent user events exist and the time for reading/writing storage module is too long. Second, a great effort is required to modify a program interface if Windows' OLE or similar component technology is to be carried out in a large and complex application that does not support component technology.